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SYSTEM AND- METHOD FOR COMMUNICATION WITH A 

I 

REMOTE NETWORK DEVICE 



Description 



Technical* Field 



5 This invention relates to the field of 

communication between digital devices such as computers 
and computer related peripherals across a general purpose 
network . 

( Background Art i 

! 1 

10 The need ,for digital? computers to communicate 

to each other and to remotely located computer 
peripherals has long been felt . Numerous technologies 
_ have been designed to meet this need, including the use 
of modems for establishing long distance links over . the 

15 analog phone network and the creation of networking 

technologies which allow computers and peripherals to 
communicate over a data transmission medium. 

"Modems are used in pairs to establish 
communication between two computers, with each modem 

20 being attached to the serial port of its local computer 
as well as connected to the analog telephone network. 
The serial port is a standard interface port on the 
.computer which allows the computer to pass a serial ■ bit 
stream of information to a peripheral such a modem or a 

25 printer. On UNIX based computers and other multi-user * 
computer systems, this same serial port is used for 
communication with the terminals which allow users to 
interact with the computer. As a result, it is a 
relatively simple matter to utilize a modem to allow a 

30 remotely located terminal -to communicate with a multi- 
user computer system over the phone lines. 

Because modern multi-user computers .are capable 
of supporting numerous simultaneous users, it is 
desirable to have a number of serial ports" through which 

35 terminals can communicate with the computer. 
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Unfortunately, mounting all of the serial ports directly 
onto- the computer can be logistically dif ficu-lt since - 
multi-user computers can often support more than fifty 
terminal connections. As a result, multiplexors have 
5 been utilized to combined serial traffic from numerous, 
internally referenced serial ports into a single 
communication channel. In this way, only one - 
communication cable needs to be attached to the computer. 
On the other end of the communication cable is another 

10 multiplexing device, which separates the combined data - 
traffic into data for individual serial ports, and then 
provides the serial ports through which this data can be 
accessed. This type of multiplexing device, called a 
ports concentrator, can be used to provide multiple 

15 serial ports for terminals in a location remote from the 
computer. It is even possible to use multiplexing in a 
system which allows the data on the main communication 
cable to be transported across phone lines using modems. 
This allows multiple serial ports to be accessible at 

20 great distances from the computer. 

Networking technology can also be utilized to 
allow remote communication between a computer and another 
computer or peripheral . Networks which connect computers 
and peripherals within a relatively small area are 

25 referred to as Local Area Networks, or LANs. A general 
purpose network is a communication system utilizing 
standard hardware and standard communication protocols, 
and operating in a multi -vendor environment. General 
purpose network hardware includes LAN technologies like 

30 Ethernet and Token Ring. Standard Network protocols 
include TCP/IP and SPX/IPxi 

LANs are generally formed by connecting 
computers and peripherals together through a transmission 
medium, and then communicating over the medium by 

35 following standardized communication protocols. These 
protocols set forth such requirements as to how data 
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*'■-!» 
should be formatted and how data is designated for a 

particular device. Data cannot be sent over the network 

without conforming . to these protocols. 

Application programs jon a host operating system 

5 generally depend strongly on the Application Program 

Interfaces (API) for local communication devices provided 

by the host j operating system. iThis is especially 

important on systems like UNIX, whose traditional user 

interface is terminal command line operation. 

10 General purpose networks most often support two 

types of communication, a connectionless unreliable 
datagram service and a reliable bi-directional bytes team 
connection. ! The API to both of these services is very 
different from the;j serial port API, and in general, 

15 programs written to run on serial devices (known as TTYs) 



require an adaptation layer to jrun correctly. j 
t , : In the UNIX environment thas is generally done 



with the network protocols Telnet and Rlogin using, a 



virtual TTY 



device i( known as a pseudo-tty or PTTY device. 

20 PTTY devices are software entities, not hardware 

| ! ; | 1 p i 

entities, that emulate UNIX TTYs weljl enough that most 
cpmmand line i programs will run jwith |them. 

vi It is important to distinguish these PTTYs from 

genuine TTYs associated with, aiid controlling actual 
25 serial port j hardware . A PTTY lias a jslave side ancija- 
master side! The i slave side of the rPTTY is the TTY 

! i ;■ ■ i 

emulation device, (and is used by programs that require 
the serial port AIJI; to function. Thjje master side 

interfaces to a network program, such as Telnet or 

1 ' • I 1 Is » 

30 Rlogin, that can send data across the network. 

t ',. - The slav^t side of the PTTYj accepts requests to 

* change user j opt ionsj like line editing characters,] tab 

expansion, and otner functions jdone by the line * 
j | l 'i ! . • 

discipline of the j^local operating system. However it 

3*5 ignores requests to, change baud rate, character size, 

I :) lit - 1 
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10 



20 



25 



30 



35 



- action on received 
like. - \ ■ ■ 



- 4 !- 



errors and BREAK signals, and the 

i , . N • : 



The master side of the 1 PTTY accepts reads,, 
writes, and_a*very 'limited set of input output controls 
(ioctls) to change Jthe way data 'is passed back and forth 
between the sllave and master devices.' 



the master side of 



the PTTY appears .as 



Data written to 
received serial 
though it had been 
serial port, and ■ is processed as input 
serial data b^j the line discipline of the operating 
system. The data then appears as received data when read 



data on the slave s]ide p of the PTTY, as 
received on a 



from the slave side! of the PTTY'/ Data 



written to the 



slave PTTY is llikewise processed as serial output: data by 
the UNIX line 'discipline, after which it can be read on 



15 the master side. 



Ioctl operations made to the 



slave side' of the 



PTTY are invisible to the master side, ! hence it is riot 
possible for tlhe program accessing the! master side of the 
PTTY to detect: thatl these calls 1 have been made. The 
interface is }ust not rich enough to support any 

operations that cannot be done 'in the line discipline of 

I h I 

the local operating! system. " 1 



It should also be notLeh that 



in most 



implementations, there is not a* one-to-one correspondence 

between physical devices and FTTYs . When a connection is 

j i \ i i I 

made into a UNIX system by ; Teliiet or Rlogin, these 

program simply allocate the next' available PTTY for the 

session. Hence from session to I session 'a network-user is 

likely to get idif f eirent PTTY devices, in no obvious ' 

pattern. This makes it difficult or impossible to' enforce 

system security or user options based on pseudo-tty 

devices. To overcome this to some extent, ad-hoc 

programs are commonly written by> terminal server 'vendors 

that can be attached to the master" side of a particular 

PTTY, so that the slave' side of " that PTTY remains . 

attached to that program and is' not periodically - 
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1 ' " " ! •': - , 

reallocated to another use. Such programs can be used 
for incoming connects and running login- programs, but are 
r most often jused tq simulate dial-out modems, printers, or 
., direct connect serial devices. . This use expands 'the PTTY 
5, (,to other uses than (Telnet and Rlogin, but because of 
their limitejd emulation of a genuine TTY device, .they 
require varied workarounds andi cause continual 



maintenance and compatibility problems. 

it Telnet also uses TCP/IP flow control for port 

10 data flow controlj^and sends commands in sequence with the 
data so that commands cannot be processed until the data 

\ ■ : x 

, ' ahead of them xn jt^he data stream haye also been 

processed. | As a jriesult, Telnejt requires the use 'of the 
-expedited data feature of TCP/IP to 1 ; send certain ■ commands 

- 1 I i M \ ■ 

15 -such as user ( requested interrupts. ( ;The implementation of 

• this requires that ( j data ahead of the user interrupt be 
. discarded before (t^e interrupt can be processed. I 

1 Unfortunately, this procedure can place a 

• - * tremendous 



strain on the host 
20' network itself. For instance, 



computer ,as well as the 

when 1 typing on a remote 

I ■■■it t j 

terminal connected (through the network, each keystroke is 
processed, jsent over the network to i the host computer, 

and then echoed back over the network to the remote 

I . it j 1J 

terminal. jOn an ^ithernet network, a transmitted) 
25 . character must be t j transmitted jon a 64 byte minimum size 
message packet and t jthe acknowledge ^lso requires :a 64 
byte-message packet. Thus, twjo 64 -byte packets must be 
transmitted for each characterj typecl. j 
, io, In addiction, the receiving of the character by 

30" the host confute retire qui res a tksk switch to run the PTTY 

control software to receive the character, and a task 

I - " - ■ 1 [ I 

- switch back to the j PTTY control software to transmit the 

I P"? . i •■ !1 ' * 

echo character. *! ' 

"I J '. • 

Devices called terminal servers make remote 
! ' 
35-- logins, utilizing the TELNET and RLOGIN commands, 

available to users through a serial port without 
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- requiring the users to be logged onto a . computer on the 
network. A user connected to a serial port on the 
terminal server can use RLOGIN or TELNET to connect to a 
multi-user computer on the network. A second user on the 
5 terminal server could also connect to the same multi-user 
computer, and thereby establish a second communications 
link with its own PTTY assigned to it. Connection made 
by the terminal server through TELNET, RLOGIN and similar 
procedures of course embody the same disadvantages as 
10 connection made using those procedures through a 
different computer on the network. 



Summary of the Invention 
The present invention comprises a communication 
system which overcomes the disadvantages of the prior art 

15 by allowing a host computer full access to the 

asynchronous ports located on a remote terminal server 
across a general purpose network. By utilizing a unique 
device driver interface and multiplexing communication 
protocol, the server is able to communicate data and 

20 control commands for multiple ports on a single 

connection, thereby reducing demands on the network. In 
addition, the present invention provides genuine TTY 
devices across the network which have all the 
characteristics of local communication ports. The 

25 present invention also makes possible access to the ports 
on the server to multiple host computers located on the 
network, allowing fair access to shared resources such as 
modems and printers. Finally, the invention can also be 
implemented in hardware, further increasing compatibility 

30 with existing host computer software and further reducing 
host computer overhead. 

The present invention operates over the 
reliable communication link provided by a general purpose - 
network between a client (usually a host computer) .who 

35 wishes co access or provide access to remote 



I 
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communication ports and a server that incorporates such 
ports . \ ; 

•!(>■;, The present invention differs from traditional 

PTTY implementations in that it provides genuine TTY 
5 devices acrjoss a general purpose network. Unlike the PTTY 
implementations/ the TTYs of the current invention; have a 
one-to-one |Correspondence with actual hardware, and allow 
the host operating system to control that hardware as if 
the serial .ports were directly* connected to the host 
10 operating sjystem arid dedicated) to this use. 

•fi. Where it^ijdoes not interfere with the u 

assumptions made by application programs, the current 
invention then loosens these restrictions, and extends 



15 



20 



25 



30 



the f unctidnality^qf these oorts to fallow sharing with 
other hostsj on the, jnetwork, ;and with dynamic port 
allocation with PBX-style hunt j groups . The present, 
ifnvention allows 'each operating system to maintain a 



correspondence with 
allow those 'TTYs fto 



H 

genudjne TTYs, but can 



one-to-one 

optionally allow ItKose'TTYs fto be accessed for other 

■ M III 1 11 1 

purposes when theynare|not currently in use by thei 
current opejrating/iis^ystem. \ j I 

mi Each" cl'ient that wishes to use one or more 

ports on the server opens a single connection to jthat 

i r * 'i t ; ' 

server utiljizing protocol provicjed by the present 

invention (ithe "Communication Protocol") . All i . 

communication between the client and server which uses 

- 5 1 " ^ : i !' 

the Communication' protocol then proceeds using this 



single connect ioni;* jno matter how maiiy ports are used by 
the client. Additional connections flbet ween the client 
and server may bej opened under I prior art protocols] such 
as Telnet asid Rlogin, however the existence of these 

M ■ ; > ■. 1 t } 

prior art" prot ocol j connect ions j does |not affect the!, ports 

under the control! of the present invention's 

1 ! ! ! " 

Communication Protocol. When the connection between the 



35 * client and 



server 



is broken jfor any 



f 



(reason, all the ports 



I 

i 
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-under CommunicatioJ Protocol control are. closed, and all 

resources claimed by that client are returned, ' 

i ' * 1 i 1 I " 

The S existence of a Communication Protocol 
| I ' \ ' ~ 

connection does not! automatically grant the client access 
:J j i; , ■ t 

5 to all port resources on the server. ! Before ■ the ■ client 

accesses a port, the client: must; first j successfully OPEN 

the port, after which time the client is granted 

i ^ . ' i i ; 

exclusive access toj the port until the I client CLOSES the 
port. . . j > j ' " ' 

10 Once a port is opened*; J the client may send 

requests to ctiange baud rate, control modem settings, and 
the like. The client may send 'data out: the port, and the 

i • i ' ; i 

server automatically sends the 1 client t all data received 

1 1 j ; ...... i i 

in the port. ..Under the Communication Protocol, the * 
15 client may request status updatLes from the server. • The 

updates can be made] immediately 'upon request J' or the 

L . i/ I 1 < 

client may request the server inform the client of iany 

j | J ; j 

changes to various status conditions (such as modem input 

i I i i ' ! 

signals) ,as they change. *■ j V ( ' 



i > i i 



2 0 Brief Description of' the Drawings ' 



Figure 1 illustrates a | general purpose computer 
I > i ' i 

networking linking a variety of 'host computers and a 

server of the "present inventionii j i» 

' Figure 2 illustrates a'i client! computer attached 

I i ) j 

25. across a general purpose network to a I server of the 

present invention, including the critical components of' 

the server . ^ ' ! 

Figure 3 illustrates a wrap-around sequence 
space with. a single sequence number pointing toward a 
30 location in the sequence space. 

Figure 4 illustrates a wrap-around sequence 
space with two sequence numbers -pointing toward locations" 
in the sequence space . m 
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Figure 5 illustrates the process by which a 
server controls the flow of data transmitted from a 
client through a server to a -port . 

Figure 6 illustrates the process by which a 
5 client controls the flow of data transmitted from a 
client through a server to a port. 

Figure 7 illustrates the process by which a 
server controls the flow of data transmitted from a port 
through a server to a client. 
10 Figure 8 illustrates a client computer attached 

across a general purpose network to a server of the 
present invention, including the critical components of 
the client driver. 

Detailed Disclosure of the Invention 

15 FIG. 1 shows a general purpose network 10 

interconnecting a variety of computers including a UNIX 
computer 12, a Digital Equipment Corporation's VAX 
computer 14 and a Novell Network of PCs at a particular 
location 16. The network 10 can utilize any of a variety 

20 of standard networking communication protocols, such as 
TCP/IP, SPX/IPX and X.25, as long as the protocol 
provides for error free byte stream data transmission. 
The communication protocol operates on a specific logical 
topology such as Ethernet or Token Ring. 

25 - - A typical network connecting the computers and 

networks shown in FIG. 1 woul~d utilize the TCP/IP 
protocol running on top of Ethernet. The TCP portion of 
the protocol takes byte stream data and converts it to 
" packets . " The IP portion takes the packets' and forms 

30" -datagrams, while Ethernet takes the datagrams and forms 
frames. This typical configuration will be utilized for 
the purpose of explaining the present invention, although 
- the invention itself is independent of the network 
protocol utilized. 
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A server 20 of the present invention operates 
to connect various ports (not shown) to .the network 10.- 
Communi cation lines 22 can be connected to the ports on 
the server 20. Although only five communication lines 22 
5 are shown in FIG. 1, the server 20 typically has sixteen 
or more ports which can be connected to the network 10. 

FIG. 2 shows the primary elements of the 
communication between one or more clients 18 and the 
server 20 across a general purpose network 10. The 

10 client 18 can be a host computer such as a UNIX computer 
12 or a VAX computer 14, or even a local area network 16. 
The server 20 is connected to the network 10 through the 
server's network interface 30. The network interface 30 
provides the industry standard hardware -and software 

15 control necessary for the server 20 to communicate over 

the network 10 in the same way as any other device on the 
network 10. As with all industry standard network 
interfaces, the network interface 30 is capable of 
receiving data frames from the network 10, determining 

20 whether the data is addressed to server 20, and, if so, 

make the data available in a byte stream form by removing 
the network formatting and reassembling the frames, 
datagrams and packets. In other words, the network 
interface 3 0 of the present invention contains the 

25 functionality of the Transport, Network, Link and 
Physical layers of the International Standards 
Organization Open Systems Interconnection (ISO/OSI) 
model . 

The byte stream data provided by the network 
30 interface 30 is then supplied to a central processing 
unit (CPU) 32, which coordinates the implementation of 
the Communication Protocol of the present invention. The 
program modules necessary for implementation of the 
Communication Protocol are stored in the program memory 
35 portion 36 of the server memory 34. 



I 
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25 



30" 



After the CPU 32 has analyzed the data received 

from the network ^interface 30,i raw data is passed through 

L to the appropriate port 40 on server 20. The ports 40 on 

the server 20 mayr t be asynchronous, synchronous or 

5 parallel ports. ^Attached to the ports 40 may be ( a 

variety of jdevices, such as terminals, printers or 

modems j * f ■ 

Data that is sent from the client 18 for 
'I i 1 T ! i ! 

transmission through the ports 40 is stored in an output 

10 or transmit 1 buffer 42 until the por^ 40 is ready to 

transmit the, data,.' Data that is sent into the server 20 

through the ports ,40 is handled similarly. The data 

coming from port 4 0 for transmission to the client 18 is 

stored in itaput or receive buffer 44 until it is ready to 

15 be transmitted over the network 10 to the client 18. The 

I i 1 ! , ' 

Communication Protocol of the present invention is 

! ! : I 

executed byj the C£JU 32 and the, step | .of formatting the 

byte , stream transmission into the frames, datagrams and 

packets required on the networ* 

20 network interface 30. 

j j The server memory 1 34 



k: 10 is handled by the 



also (, contains server state 



variables 38, which contain the status information 
necessary to fully ; t implement the Communication Protocol 
The ! types of servjer state variables 
preferred embodiment of the] present 



in -Table l . 



■I/J 



38 stored in |the 
invention are shown 



These variable types represent a variety of 



in various ways to control 



data , structures , »and are used : 
the t workings of the server 20 and to facilitate , 
communication between the client 18! and the server, 20. 
To clarify the purpose of .these variables, they are 
.discussed below in (detail. , 



clients 18 
1 



V 1 ■ ? 

The Client Connections list maintains a .list of 

■ " I i | ! f ! 

that currently have a connection with the 



35-- server 20 open under the Communication Protocol, iln the 
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preferred embodiment, the server 20 can support 1( eight or . 
more simultaneous |client connections . j .* . " 

The Message Build Interval controls the polling- 
interval to det ermine how often! the server 2 0 internally 
5 polls its state to determine whether; information needs to 

be constructed according to the! Communication Protocol 

.'!. [.I 
and transmitted to; the client 18. In the preferred 

f - 1 . ■ . I 

; embodiment , this polling takes nplacej approximately fifty 

j times per second. This results in at worst case delay 

10 time of twenty milliseconds , with an average of ten 

milliseconds. 1 Thi's is adequate 1 for users at terminals, 

I : t , j 

and for most sliding 'window protocols! f 



By j transmitting information 
build interval, th'e server 20^ is able 



only at the! message 
to accumulate 



15 i information during the interval!. Thus, data is sent in 
larger packets tha'n if data were sent a character* at a 
time, which l|imitsj the demands on both the network 10 and 
the client 18. j #j ' . J j j 

i The Port] Open State I variable is a i da tar j 

20 'structure which tracks which clients, 18 have a connection 

i t 

! open to a port 40 ,| and which clients] 18 are , waiting to 
' open that port- 40. 1 In other words, for each open port 40 
| this data structure tracks which client 18 currently 
, holds the port 40 and which clients 18 are on the Open 
25 -wait list. Further details on opening a port 40, are set 
' forth below, j , j 

1 The Port 1 Baud Rate variable j stores the baud 

. rate of each port 40 in such a way that the baud rate of 

the port 40 is 1,843,200 divided by tne Port: Baud Rate 
30 variable. Ttiis representation (requires only sixteen bits 
■ to represent all standard baud urates in the , range (50- 
i 115K Baud. i i • if 

1 The Processing Flags (variables control , 

character size, hardware states and input/output 
35 i character processing for each port 40. There are four 

sets of processing flags that are stored in the server" 
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state variables: CFLAGS, I FLAGS , O FLAGS AND X FLAGS . 
CFLAGS, I FLAGS and O FLAGS are standard flags provided by 
in the termio interface of most standard UNIX operatinq 

U I ; j ' , i * 

systems, and are used in the present invention as is 

f ■• ; | ,| . , | ■ I 

5 standard in the industry. (Unix Programmers Manual, 
Termio ) .1^1 I 

CFLAGS has settings which control UART hardware 
settings on | the port 40, including character size, stop 
bits, and parity. The actual CFLAGS, settings that it 

10 makes, sense " ' ^ 

i t i. 



to implement in the server 20 include CBAUD, 

■ I 1 H : I \ 

csize; CSTOPB, CREAD, PARENB, EjARODD; and HUPCL. 

Similarly, I FLAGS has settings which;' control the 

i I < f M 9 
processing of data at the server 20 received from the 

, n < ,; i ' > 1 1 "> . . ; « 

port 40. I FLAGS settings include control over the 

15 interpretation of ] Break conditions, error handling and 

software flow control settings. 1 The;' I FLAGS implemented 

on the server 20 are IGNBRK, IGNPAR , J PARMRK , INPCK, 

ISTRIP, IXON; IXOlj'Fj IXANY, DOSMODE . ^ O FLAGS controls the 

server 2 0 processing of dataj intendejji to be output ted 

20 over Ihe port's . 40 i J ] OFLAGS settlings control such things 

as CR ; and NL settings and tab delay, and are defined by 

termio to include 'oPOST, OLCUcJ ONLCR, OCRNL, ONOCR, 

r i i W ! i i " 

ONLRET, OFILL, OFDEL, NLDLY, CRDLY, TABDLY, BSDLY, VTDLY, 

f;fdly! ' i ! 

25 In the preferred embodiment, various flags 

. -I ' * I ■ - 1 \ . [ f 

settings which are. no longer used with modern 

communications equipment are not supported. These flags 

settings include OFILL, OFDEL ,~[NLDLY^ CRDLY, BSDLY, VTDLY 

and FFDLY, all from? OFLAGS. Each of.' these settings could 

30 - be supported with only slight modifications to the 

:i n s i Kl i * 

preferred* embodiment , but the decision whether or not to 

- i -. i ■ i } \ -i i * i* 

- support these setting is irrelevant to the present 
invention. | 1 j ^ 

X FLAGS is. a set of flags taken from termio 
35 _ - LFLAGS , plus some additional functions. The XFLAGS 
settings are set forth in Table 2 . 
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The XFLAGS variables (except for XCASE which is 
a UNIX line, discipline or LFLAG variable) are .extensions, 
to the UNIX feature set either to expand the interface to 
multiple host operating systems or to provide value-added 
5 features. These XFLAGS settings interact with the 

settings of the CFLAGS, I FLAGS and OFLAGS settings. The 
details of the interactions are as follows. 

If the XPAR setting of XFLAGS is reset or if 
the underlying hardware does not support mark/ space 

10 parity, then the PARODD setting of CFLAGS selects odd 

parity if set and even parity if reset. Otherwise PARODD 
selects space parity if set and mark parity if reset. 

If PARMRK of I FLAGS and XMODEM of XFLAGS are 
set, any change in one or more modem signals is encoded 

15 in the input stream as FF 80 MM, where MM is the updated 
modem signal value. 

If XCASE of XFLAGS is set, certain non- 
alphabetic printing characters are converted to two- 
character equivalents on output according to UNIX 

20 specifications. 

XTOSS of XFLAGS controls whether a character 
that resumes output during flowing control is ignored or 
not. When IXANY of I FLAGS is reset, output is restarted 
only when a matching XON or XXON character is received. 

25 However, when IXANY of I FLAGS is set, any received 

character resumes output. Thus, if XTOSS is set, the 
character that resumes output is discarded. If XTOSS is 
reset, any non-flow control character resuming output is 
placed in the data stream. 

30 When XIXON of XFLAGS is set, an extra set of 

output flow control characters is enabled. Receipt of 
XXOFF stops output while XXON resumes it. 

The Flow Control Characters variables determine 
what the flow, control characters- will be. Two sets of 

35 output flow control characters are supported and one set 
of input flow control characters is supported. In 



1 
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10 



15 



20 



25 



addition, a flow control escape character is supported to 
allow input) of flow control characters without 
interpretation. The Flow Control Characters include 1) 
the standard software flow control start character , (XON) , 

't ). | ' i j ! 

2) the standard software flow control stop character 

' : : i; I I T'i I ' ; " 

(XOFF) , 3) the extra software flow control start 

jl Pi 1 

character (XXON) , the extra .software flow control stop 
character (XXOFF) .and 5) the| flow Control Escape 
Character (LNEXT) . | j 

ijt After receipt of the LNEXT ^ character, the next 

character received^ is not recognized as a flow control 



character, and both/ characters 
data stream] 



are placed into the input 



Returning to the Server State Variables 38, the 
provision of full j modem control , facilities to the' client 
18 are provided through eight Modem Control variables. 
Each of these 1 variables use masks to represent the 
operating state ofi^a modem. , The seven modem variables 

\'r | . ; I 1 !'! i [ 

are set forth as follows in Table 3. r 

! I. ' t. " 

of modem signals, using the bit: assignments shown 1 in 



! r 



All variables shown in Table 3 represent ! sets 



Table,, 4 . 



The use >pf the different Modem Control 



The 



MOUT Modem Control 



variables are as follows. 

- 1 'i i 1 i 

Variable" contains >the values of RTS and DTR last 

- i ■ I - f'M I I ! -I 

requested by the client 18. These vp.lues are changed by 



issuing a request 
bits, in MFLOW are 



MOUT, 



t po the server 20. t- When the RTS /DTR 



jSet, the corresponding values set in 



, are temporarily ignored, and those signals indicate 



30 - whether the 



server ,20 is ready 



receive is paused;, . these signals are driven low. When 



to receive data. When 



• I 1 



rece 



lye ~is restarted, the signals arjp driven highj. 
i i MFLOW is used to inhibit the "in-band" output 

of data. Data, commands, and responses that are handled 



35 in the same 
out of data 



-sequence as the normal flow of . data in. and 
ports pis called in-band |data. Data, 
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-commands, and ^ responses that are' transmitted ahead '.of 

normal data, and are processed^ immediately upon receipt - 

are called out: -of -band data. in'- band output is inhibited 

when any of CTS/DSR/DCD/RI are j set in MFLOW and at least 

one of the corresponding hardware input signals is low. 
\ 1 — ] I 

Flow control characters and, transmit immediate 

characters are not 'governed by' software flow control or 

MFLOW. They Jre transmitted according j to the 



CTS/DSR/DCD/RI flow 



control constraints given by MCTRL. 



The server 20 'automatically resets anyjbit in MCTRL that 
is not set in |MFLOW;. r 1 

MST^T contains the current state of the 1 input 
and output modem signals. * 



contains the lalst modem status reported 



to the client a8 . ' < 

MTRAN contains the modem signals that have - 

changed since they were last reported ; t:o the client 18. 

f i i j 

It is possible' for MS TAT to equal MLAST and still* 1 have 

b'its set in MTRAN. 'This condition indicates that some 

signals in MS TAT ma^e at least one transition,; and then 

returned to the value last reported to Jthe client '18. 

When 1 any of the six modem signals are set 1 in 
tl !' • ' I 

MINT, corresponding < changes in those modem signals are 

reported to the client 18. 1 1 '<» 

The Server 20 of the present 'invention ' 

maintains per-port statistical counters in the server 

state variables 38 tlo keep track of the number of 1 receive 

character errors occurring on that port 40. These 

t ' i 1 1 ' 

counters are referred to as the, Line Error Counters. A 

different counter is utilized to^j track each of the 

following counts: the number of UART overrun errors, the 

, t j 

number of buffer overflow errorsV the number of framing 

errors, the number of parity errors and* the- number of 

breaks received. Each of these ' variables are 16 -bit 

wrap-around counters that keep track of the number of 



I 
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25 



35 



_ t 
line errors that have occurred 



in each category for that 

J 



port 40. 

1 ■ 1 

An additional Line Error Counter variable 

<* ■ ! "il 

tracks the report time in milliseconds. If this variable 
:■ ti | I 

5 is zero, line errors are not automatically reported to 



the client 18 . 



Otherwise the server 20 inspects the 

a complete 



counters at each specified interval, 1 ' and sends 

; i (..T. t jj 

report to the client 18 if any have changed since the 

H 1 ..; f 
last report . ,1 

' 1 I 

The Send Break and Send Immediate variables 

: i h i j, : 

allow a client 18 ^to request the server 20 to immediately 

a Break; or another [character to a port 40. 

•11 . ! f 

a one; character buffer 



send either 



The Send Immediate variable is 

which contains the character that the client 18 wishes to 

i ! | M . : I 

The Send Break variable 



15 send. 



JM'! 



't. 



contains the length in 



milliseconds • of the { requested break.. Two special cases 
exist in the | contents of the' Send Break variables. When 
an FFFF value is sent to Send Break, \ this denotes an 



infinite break timei 



A 0000 sent to; Send Break cancels 



any break in progress . Any other value sent to the 

server 20 is < simply added to< Send Break time, and' the 

| 1 . ■ M I [I 1 

break proceeds for the combined duration of the two 

I ' : f 

requests . , , { 

i.i ' h, : J | 

Since the; current invention does not utilize 
I- 1 I i \ \ 

TCP/IP flow! control, for port flow control, data received 

I , • * ,i i 

by the client 18 orf server 20 can always be immediately 



processed. As a 
commands and data 



result, 



data . . 



30 - 



it is 



without disrupting 



easy to send out -of -band 
the flow of in -band 



The server 20 also maintains a list of 



conditions in the ^Server State 



Variables 38. 



status 
These 



status conditions ! are stored in the Event Reporting 
variables, and represent conditions that are of general 
interest to -the client 18. The client 18 can poll these, 
or request that the server 20 automatically send the 
appropriate event information whenever the conditions 
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change. The Event Reporting variables allow the server 
20 to track the sending of this event information. Table 

5 sets forth the various Event Reporting variables. 

EINT can be set by the client 18 to create a 
5 predetermined condition which will cause event 

information to be sent by the server 20 to the, client 18. 
Event information is sent to the client 18 whenever 
(ETRAN & EINT) is non-zero. 

Note that it is possible for ESTAT to equal 
10 ELAST and still have bits set in ETRAN. This condition 

indicates that some conditions in ESTAT made at least one 
transition, and then returned to their ELAST values 
before they could be reported to the client 18 . 

The events that are recorded in these variables 
15 are set forth in Table 6, along with the masks which show 
how the events are indicated. The events listed in Table 

6 are communication events well understood in the context 
of this invention. 

The last two types of variables stored in the 
20 server state variables 3 8 are the Input Sequence and 
Receive Buffer Parameters variables and the related 
Output Sequence and Transmit Buffer Parameters. These 
variables represent the state of the transmit buffers 42 
and the receive buffers 44 which are associated with each 
25 port 40. 

To communicate the flow of data in the buffers 
42, 44, the preferred embodiment of the server 2 0 uses 
sixteen bit wrap-around sequence numbers. Two sequence 
numbers are associated with each buffer 42 , 44 . The 

30 first sequence number communicates the sequence number of 
the next byte to be placed into the buffer. This first 
sequence number is labeled RIN for the receive buffer 44 
and TIN for the transmit buffer 42 . The second sequence 
number communicates the sequence number of the next byte- 

35 to be removed from the buffer. This second sequence 

number is labeled ROUT for the receive buffer 44 and TOUT" 
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25 



for the transmit buffer 42 . These sequence numbers begin 
at . zero and advance by one for each byte of data 
transmitted i or received. When, the sequence numbers reach 
FFFF, they wrap back to zero and continue when the next 
byte of data , is transmitted or (received. It should be 
noted that the TINi, , TOUT, RIN, tand ROUT variables are 
sequence number variables used j to communicate between the 
client 18 and the ^ server 20. They do not specify the 
physical positions of data in the transmit and receive 
buffers 42,j44, which is done through techniques well 

known in the art and not described herein. t 

■ . j . - . : i i 1 

-i« These sequence numbers, and the other variables 

whichi make up the p Input Sequence and Receive Buffer 
Parameters and 1 the Output Sequence and Transmit Buffer 
Parameters variable! types are shown fin Tables 7 and 8 . 

i r! ■ I ' 

lj i Wrap-around sequence numbers like TIN, TOUT, 

RIN and ROUT have isbme very helpful ■mathematical 



properties . 



; However , sequence 

; i in | i ^ i 



numbers can be confusing, 
and subtraction, since 



30 - 



especially when d(j>ing addition 

special definitions] of these! functions must be used as a 

result of their w^rap-around nature. | 1 

u i To clarify their use] an example embodiment of 

a^ transmit buffer j 42 will be discussed, as illustrated in 

FIGs . 3 and 4 . In, the embodiment ofj FIG . 3 , the TOUT 

sequence" po: Inter ^pointing to the nejxt byte of data to be 

transmitted out of* the buffer 42 to !a port 40 and t 

represented in FIGu 3 by arrow; 50) is set to byte | S. 

When, n bytes of data are transmitted^, the transmitted 

[ 'M , i | 

bytes are numbered . S though S + (n -' 1). By convention, 

we say the buffer r 'has transmitted by t tes between S ( and (S 

-+- n) However, since we are adding jan ordinary number to 

|-t * I - "..ii.. U • [■ 

a; secjuence number that wraps at OxFFjFF, we must compute 

the expression S + 1 n using the ! following formula:) . 

(S + n) & OxFFFFj ' ; 
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with & indicating a 'logical AND operation. Tnus, where S 

- . " v -i i . t i -i * . - 

is 0xFFF8 and n is 5, the formula for computing S-+ n 

give us OxFFFC; Similarly, where' S is 0xFFF8 and n is 9, 



S + n is 2. 



=J I I 

After transmitting n bytes, the TOUT sequence 

pointer must be advanced to the new location of the next 

byte to be transmitted. This is ' done by replacing the 

old value of TOUT with the computed result S + n. 



To determine the number 



of bytes that exist 



10 between two sequence; number, subtraction is used. 



However, a special rule must be used to 

result of the subtraction of one sequence number from 

'j ! , j 

another. Thus^- to determine the number of bytes between ( 

sequence number si and,s2, the following formula is used: 



determine the 



!(S2 - si) 



&i0xffff 

i * 



This 'formula works even if sequence si is 



r 



numerically greater than sequence number s2 . For 
example, if si k OxFFFO and s2 = r 3, then (s2 - si) 
OxFFFF is 0x13,' the jcorrect answer. 

In fact the concept of ¥t iiistanc:e between 
sequence numbers is so important 'that it is useful 'to 



define it as: 



to) = ({(toV- (from)) & Oxffff ) 

Ml ■< !• 

Giveri a pair ' of sequence numbers si and 's2 , it 
.at s3 is the seq 
between si and s2 only if: 



DIST(from, 



h I ; . m I 

is true that s3 is the sequence location of a byte 



DIST(sl, S3) < DIST 



Si, s2) 



This formula can be read as: n _s3 is between si 
and s2 if and only if the distance from si to s3 is less 
30 than the distance from si to s2 . " ~ 
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Seguence numbers can^ communicate the amount of 
data, or the amount of free space in a remote buffer. 
Assume that in the transmit buffer 42 for a particular 
port 40, as shown^ in FIG. 4, the TOUT sequence number 50 
5 ; is set to si, while the TIN sequence number 52, 

representing the next byte to be transmitted through the 

: port 40, is, set to, S2 . In FIG. 4, both TOUT and TIN are 

I i 

represented' by arrows pointing to locations in transmit 
buffer 42. It is possible to determine that the number 

10 of bytes in the transmit buffer 42 for ,that port is: 

i 

I ! 

r, i DIST(sl, S2) 



In; addition, if the transmit buffer 42 for that 
port is of fixed size SIZE, , it ! is clear that the number 
of free bytes in the buffer is: 

i ] ; i 

15 SIZE - DIST(S1, s2) 

t Both the client 18 and the server 20 of the 

present invent i on f make use of the special characteristics 
of the wrap!- around, sequence numbers jto control the in- 

band flow of information between them. Both client 18 

! T' i f 

20 j and server 20 send in -band data to the other only when 

pre -author! zed to, do so. This j pre -authorization is 

accomplished by communicating the amount of data that the 

! 1 1 t it i 

other is allowed to transmit to it. £ When the sender has 

data tjo fill this "space ,| the sender pauses in 

25 transmission until the receiver removes some of the data 

i 

the sender that additional space is 



sent pnough 



" and informs 
"available. 

-To control the flow from client 18 to "server 

! r 

20, the server 20 provides the j client 18 with the size of 
30 its transmit buffer 42, and the sequence of the first 
byte currently in the transmit buff er 42 (TOUT) . The 
client 18 keeps track of- the data that has previously 



WO 95/2531 1 PCT/US95/03183 

- 22 - 

been sent to the server 20 by keeping its own client 18 
send sequence number. By using this send sequence, 
number, along with the information provided by the server 
20, the client 18 can compute the amount empty space left 
5 in the server's transmit buffer 42. The client 18 

therefore will not send any more data than will fit in 
that empty space. 

This process is shown in detail by the flow 
chart of FIG. 5. The indication to start transmitting 

10 activity is shown in box 100 on the chart. The first 

step is to determine whether data has been received from 
the client 18 through the network interface 30 of the 
server 20. If so, as indicated in box 102, it is 
necessary to receive the data and place the data into the 

15 transmit buffer 42 for the appropriate port 40. Whenever 
data is placed in the transmit buffer 42 , TIN is 
incremented, as is shown in box 104. 

Whether or not data was received from the 
client 18, it is possible that data exists in the 

20 transmit buffer 42 that can be sent out through the port 
40, as shown at query box 106. If data does exist, the 
data in the buffer 42 should be sent out over the port 
40, box 108, and TOUT should be incremented, box 110. 

At this point, the server 20 must determine 

25 whether it is necessary to report TOUT to the client 18. 
Three tests, indicated by query boxes 112, 114 and 116, 
are utilized in the preferred embodiment. The first test 
112 compares TOUT, which indicates the next output byte 
to be transmitted, with TPOS . TPOS is one of the Output 

30 Sequence and Transmit Buffer Parameter variable stored in 
the server state variables 38. TPOS indicates the last 
value of TOUT that was reported to the client 18. If the 
difference between TOUT and 1MAX, computed using the 
sequence number subtraction formula described above, is 

35 greater that TMAX, the TOUT will be reported. TMAX- is 

also stored in the server state variables 38, and is set 
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by the client 18 to determine the transmission intervals 
at which TOUT will be reported. Note that whenever TOUT 
d^s reported to the client 18,. at box 120, TPOS is then 
set to the value of TOUT at box 122 4 , 
1 The second 1 test for reporting TOUT, at Box 114, 

determines whether, the data was in the buffer 42 at least 
TTIME milliseconds ago, and since tljat time TOUT has not 
been reported, with TTIME being a server state variable 
38 which can be set by the client 1£ . If so, TOUT, will 
l^e reported to clpLent 18 . 1 1 i( 

The final test, 116, { compares the value of TOUT 
with the value of TREQ. TREQ, j stored as one of the 
server state variables 38, is set by the client 18 so 
that when TOUT passes TREQ, TOUT is jreported to the 
client 18. Mathematically, to compare the wrap-around 
sequence number TppT with TREQ^ it is necessary to test 
their relationship by comparing whether {TIN - TREQ) is 
greater than or equal to . (TIN j- TOUT) , using the sequence 
number subtraction formula described above. If TOUT has 



passed TREQ,, then^TREQ becomes 

I J 

TOUT is reported to the client 



invalidated, box llj8, and 
18, box 120. . 



^ To allow for flexibility in the client 18 

djriver software, jtjie client 18 [ may send data to the 
server 20 whenever it is convenient 

- n ! 1 ' t 



25 the client 

- I'i 

puffer 42. 



to do so, so long as 
18 does, not overflow the I server' s transmit 



The 



procedure for making sure 



that the 



transmit buffer 42, 'does not overflow is shown in FIG. 6. 

T 1 p t : . i |i 

When a client 18 wishes to transmit data to a 
port 40, the driver on the client 1^, vhich is handling 

the Communijcation ( Protocol for, the client 18, must 

V j ! i • I 

request that the server "20 open the j port 40 for it, as 
.shown ih box- l30.^ ( ;The details; of opening a port 40 are 
explained below. After a successful: open, the client 18 
assumes thJt TSIZE,! the size of the (transmit buffer 42 

I r ■ 

connected t'o the boen port "40, 
addition, the client. 18 .resets 



and TOUT are zero, j In 
its own Send Sequence 



! 
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Number, which! is a 'Wrap around sequence number variable 

stored and maintained on the client 18. The client 18 - 

then requests < TSIZE from the server as shown in box 132. 

Note that the client cannot actually s'end data, as shown 

5 in box 140, until TSIZE is received from the server 20 as 

explained below. i i . \ 

The if client 18 next determines if data has been 
1 - ■ * I i - 

received from the host computer,! at" box 134. If Idata has 

Ipeen received] the data must be prepared for ' 

10 transmission, ?box 135. The preparation for transmission 

1 i t 1 

is later discussed in. detail. ; h j 1 

The 1 client 18 then tests if there is any data 

I ! t ! 

to be sent at box 1G6. " If data iis reacly to be sent, the 

client's driver must compute tfie| maximum number of bytes 

15 that can be accepted by the server 20 without overflowing 

the transmit buffer 42, box 138:* This is accomplished by 

comparing the (client ' s Send Sequence Number with the most 

i i j ' i I 

recently reported value of TOUT/- and subtracting l this 
i , 1 i 

difference from TSI;ZE: i 

; • '-.« 

20 1 \ Max !# Bytes to Send = 

I ! TSIZE - (Send Sequence # - TOUT) ) 

I I I i .1 ! 'I , 

! t \ • 

Of course, the subtraction of the sequence number TOUT 
from the client's Send Sequence 'Number 1 must be done in 
compliance witih the' formula for 1 subtracting sequence 

25 numbers. f , ' ! it . f - 

t 1 ) it 

If the calculated maximum number of bytes to be 

sent is greater than zero, box '1)40, then up to that 

number of bytes can. be sent to the server 20, as shown in 
i i 1 I 

box 144. The (client's Send Sequence Number must then be 

30. incremented by the number of bytes sent, box 146. 

Regardless of whether data has been sent-; the 

client 18 must next determine whether the server 20 has 

transmitted the value for TOUT or TSIZE, as shown in box 
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148. If so, the ^alue of TOUTj or TSIZE as stored at the 
client 18 is updated, box 149. ( 
I, , To avoid falsely reporting that the transmitter 

is idle when it is not, the ( server 20 recognizes a very 
5 | special case. When the transmit buffer 42 is empty, but 
the UART is still^ tiusy sending in-band data, the server 
20 reports (TOUT p 1) instead of TOUT. This convention 
i allows the clientj 18 to assume all ^ata has been 
successfully sent^when the client receives TOUT equal to 
10 the Send Sequence; Number of the last data sent to the 
i server 20. M j 1 

The handling of dataj received from the port 40 
and transmitted from the server 20 to the client 18 is 
shown in FIG. 7. The server 20 is not authorized to 
15 transmit data to the client 18j until the server 20 

receives a value ,for RWIN, as 'seen in box 150. RWIN is 

1 i > 1 i 

an Input Sequence and Receive Buffer variable which is 

I ; - r t 1 ! ! 

; set by the (client < 18 to- indicate the highest sequence 

- l M ,| 1 

number the client ,1 8 wishes to accept. 

20 . ,)t When the j initial RWIN is received from the 

client 18, the server 20 examines the port 40 to see if 

incoming da*ta is 'available to be placed into the receive 

, buffer 44, [shown at box 152. 'if data has been received, 

it is placed in the receive buffer 44 and the RIN 
_ | j i l 

25 j sequence number is incremented accordingly. This is 

- I " i ' - I 1 

shown in box 154 and box 156. 

Because it is not known by the server 20 how 
I ' 1 I - I 1 

cruickly the client! 18 will be~jable to receive data from 

I i | i 

20, the 1 server 20 has the ability to implement 



.the server 

30' input flow controjLjon the port: 40. , Flow control; is 

".initiated when the I amount, of data remaining in the 

- ' - " I- - * 11 T ■ -■!!•■"?" I . 

- .receive" buffer 44 (calculated 'as RIN - ROUT) exceeds the 

j 71 . ; I 

value of R.HIGH, another Input Sequence and Receive 
Buffer. Thus, after data has r be en placed in the receive 
35-- buffer 44 and RIN has been incremented, the server 20 

determines whether input control shall "be invoked, boxes 
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162 and 164. Flow control is released when the amount of 
data-in the receive buffer- 44 drops below Input Sequence 
and Receive Buffer RLOW, which is tested after data_ is 
sent to the client 18 as shown in boxes 158 and 160. 
5 If the review of the port 40 in step 152 did 

not find new data on the port 40, the server .20- then 
determines whether data is available to be sent in the 
receive buffer 44. If not, as indicated in FIG. 7 at box 
166, the server 20 again waits for data at the port 40. 

10 If data is available on the receive buffer 44, 

then the server 2 0 must compute the maximum number of 
bytes that can be sent to the client 18, at box 168. The 
number is determined by the simple formula (RWIN - ROUT), 
calculated according to. the sequence number subtraction 

15 formula. If the maximum number of bytes to send is zero, 
then the server 20 must wait for RWIN to be updated, 
shown as at query box 170. If the calculated number is 
greater than zero, then the server 2 0 must determine 
whether it is appropriate to send the data bytes to the 

20 client 18 at this time. Two tests are used to trigger 
the sending of data. The first test, at box 172, 
compares the number of bytes in the receive buffer 44 
(RIN - ROUT) with RMAX, an Input Sequence and Receive 
Buffer which can be set by the client 18. If the bytes 

25 in the receive buffer 44 exceeds RMAX, then up to the 

maximum number of bytes allowed is sent to the client 18, 
box 176, and ROUT is incremented accordingly, box 178. 

If the number of bytes in the receive buffer 44 
did not exceed RMAX, then the server 20 determines if 

30 data has been in the -receive buffer 44 at least RTIME 
milliseconds ago and since "that time data has not been 
sent to the client 18. If so, then, as shown in query 
box 174, data is sent to the client 18. 

If data is not sent to the client 18, the data " - 

35 remains in the receive buffer 44 until one of the two 
conditions for sending data, 172 or 174., becomes true. 
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10 



15 



20 



30- 



35- 



j After a port 40 is opened; RMAX is initialized 

to one, RTIME to zero, RLOW to 1/4 RSIZE, RHIGH to 3/4 
RSIZE and all thenisequence numbers are zeroed. These 
variables however^, can be altered as ^ desired. 
^ Generally, the server 20 sends all available 

data for edch port ^40 when it sends f any data for that 
port 40, unless it is restricted by i the calculated 
maximum number of bytes that can be j sent . This 
convention reduces the number of packets both server 20 
and client j!8 must process, and generally improves client 
ij.8 efficiency. j 

On the client side, in the host computer^ the 



operation of the invention can 



upon the operating j system of tie host computer. For the 
describing the operation of present invention 



purposes of 
on a client 



vary f greatly depending 



18, tJjie implementation on a UNIX host ^system 
will be outjlined, -as shown in Figure 8. The invention 
provides access tojthe ports 40 on |he server 20 j through 
a client driver 200 



whic 



|l impl 



ements the API 



the use of 

of the host| operating system by emulating a driver for a 
set of locally connected serial ports 204 
the client 



To do .this, 

driver^OO maintains for j each remote server 



oort 204, an input . or receive buffer 206, an output or 
transmit buffer 208, and information concerning the state 
25 of. the remote serjver 20 as well as |he interface j to the 
host computer, which are stored' in status memory 210. 

- - The driver 2 00 also interfaces to a standard 

I ! ' i _( ' - I 

network interface] 212 which is' connected to the general 

purpose network 1.0.. All communication from the client 
~ . . | ( ' : ! IC i 1 

driver 200 to the.jserver 20 is- transmitted over the 

1 ' | \ * } ■ i. 

network interface. 212. maintains jOnly one 



network 10.i The 



.connection 
regardless 



over the network 10' for each server 20 ,» 
of the^ number of ports 40 that the.drivjer 200 
has open under the j Communication Protocol. i 

I When the tsystem is booted; the operating system 

| i j i 1 ;i . - ' i 

start-up. procedure initializes the driver 200,- and for 
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-^ach server 20 starts up a user mode daemon 214 which 
!' i . j - 1 - - 

opens a STREAMS connection 218it'o the' server 20. - _The 

daemon 214 then opens a STREAMS connection 220 to a, 

control device' 202 associated with the 'driver 200. The 

Daemon 214 next, using the STREAMS interface, requests 

that the operating system link the stream 218_- below the 

control device^ 202 so that the driver 200 can directly 

send and receijve data on the network connection to the 

server 20 w/o further interaction from I the daemon 214. 

10 By doing so, the driver 200 is aille to |both transmit 

from the server 2 0 



eliminates the task switch overhead 



queue service routine of the control 



TCP/IP data to] and receive TCP/IP data 

in the STREAMS 

device - This 

required by the prior art. 

15 ! The connection made is 'a bytes t ream connection, 

allowing the driver '2 00 to reliably send and received 

sequenced data, to tlie server 20 .' 1 The driver 200 relies 

completely upon the j reiiabilityj of this connection and 

has no provision to ' retry for ldst packets and the like, 
i , i i \ -A i 

20 Should the driver 200 ever detect an error in the data 

received from the server 20, the 'driver 200 passes a 

I j It! 

hangup signal up to the daemon 214 , which then closes and 

attempts to reopen the connection to the server 20. 1 Such 

an error cannot occur during normal operation. The error 

25 can only occur 1 due to a failure 1 'of the ^remote server 

software, the networking software, the 'driver software, 

i ' I | i j ; 

or some sort of computer failure'!. The standard TCP/ IP 

[ t j ; I 

software in the host computer effectively insures 'this 
sort of error cannot occur due to lost or garbled packets 

30 as normally happens Ion a general' purpose computer "network 
10. * . 1 

Once' the driver 200 has access to the network 
connection, the driver requests' the server 20 to return 
information as "to the number of serial ports 40 on the - 

35 server 20, and other hardware and software 
characteristics of the server 20. - "* 
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When a user mode task 216 attempts to open a 
TTY serial port 204, the host operating- system 215 makes 
} an open call; to the driver 200. If ^the port 204 .is not 
. already open by another user mode task 216, the driver 
5 j sends an open request to the server .20 to gain exclusive 
access to the port , 40 on the server ,20 associated with 

! ' ^ t i ) 

ji the TTY port 204 of the driver* 200. jlf the port 40 is 

available, the server 20 responds, granting exclusive 

access to the client 18 until the client 18 closes the 
> . rr ■ | l | 

10 P,ort 40, or! the connection to the client 18 is lost. 

. : ik. the port 40 is not available, the action 

taken depends on the type of open request originally made 

),bv the user mode task 216. 'A user mode task 216 may 

request thati the open fail if it cannot be done 

15, immediately, ; or it may request j that | the request wait 

until the port 4 0 becomes available i In the former case, 

_ i the driver 20 0 requests an immediate open to the server 

- i ' j } 

20, which the server 20 rejects if the port 40 is busy, 

ii ;f T 

and the driver 200 t theri returns an error to the user mode 



20 



25 



task 216. jlh the, latter case, 
waiting open to the server 20, 
queue of wajiting clients until 
becomes available ,j The server 
indication !that the request is 
puts the user mode rtask 216 to 



notifies the' driver 200 that the port 40 is available. 

- " Once the idriver 200 

server port! ^0, tl^e driver 20t> 



the server 



V 

the driver 200 issues a 

I 

asking to be put on a 
the port 40 eventually 
20 then returns an 
queued, and the driver 2 00 
sleep until the server 20 



ias successfully opened a 
sends inquiry packets to 



20 to learn the hardware "and software 

! i* it t | I 



30' characteristics of j the port 40, including the hertz value 

i 1 r I < 

"of the baud rate generator, and whether the port 40 can 



.support" mark and t space parity, 
the server 



The 1 driver 200 also sends 

I 1 " 

receive buffer 206 for port 



35-- 



20 the size of the 

2 04 so that - the server 2 0 knows how much data can be 

t , - j 

received by* the client 18 without further, authorization. 

i i 

The server 20 responds to the inquiries, sending the 



t 
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-characteristics of the port 40 , and including the size of 
transmit and receive buffers 42, 44 of the port 40. 

When the driver 200 has received the reply from 
the server 20, the driver 200 is ready to send and 
5 receive data to the port 40, and make control and status 
inquiries on behalf of a user mode task 216, jwhen 
requested to do so by the host operating system 
open / close / ioctl (input/output control) interface. 
Thereafter, all data received on the port 40 of the 

10 server 20 is automatically sent to the client 18, where - 
it is stored in a receive buffer 206. The server 2 0 is 
initially authorized to send as much input port data as 
will fit in this buffer 206, but no more, so there is no 
possibility of a buffer overrun. 

15 When a user mode task 216 requests to read 

data, the host operating system calls the read routine of 
the driver 200. If sufficient data has been received 
from the server 20, according to the parameters of the 
read request, the driver 200 returns that data to the 

20 host operating system 215 which in turn passes the data 
to the user mode task 216. If sufficient data is not 
available, *the driver 2 00 puts the user mode task 216 to 
sleep until the data arrives, or until the read request 
times out or is interrupted according to the API of the 

25 host operating system 215. 

After the driver 200 has removed data from the 
receive buffer 206, the driver 200 informs the server 20 
that this data has been removed by incrementing a 
sequence number (RWIN) by the number of bytes removed, as 

30 described above. The server 20 is then authorized to 

send additional data until that data reaches the sequence 
number RWIN. 

When a user mode task 216 requests to write 
data, the host operating system- 215 calls the write 

35 routine of the driver 200. If the driver 200 then .copies 
as much of the user data as will fit into the transmit 
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buffer 208. If all of the data could be placed in the 
(transmit buffer 2 08, the server 20 completes the request, 
and the user mode^task 216 is allowed to continue .[ If 
not all of | the data fit in the transmit buffer 208, the 
5 jdriver 200 jputs the user mode |task 216 to sleep until 
data can be sent jto the server 20, freeing up enough 
space in the transmit buffer 208 so the remaining data 
^can be placed in jthe buffer 20^8. j , 
tjj. VjJhen a user mode task 216 j makes a control or 

10 ^q^ry request (known as an ipctl request), the j host 
operating system ^15 calls the 1 iocti routine in the 
driver 200 J j If the request is to change the hardware or 
software characteristics of the por^. 204, the driyer 200 
motes the change ^n the status, memory 210, and sends a 
command to the server 20 to make the necessary changes. 
If the request is (an inquiry request which the driver 2 00 
•;can respond to without consulting the server 20, the 

will do !so. If the request requires data in 



15 



20 



(driver 200 
.,the server 
fthe server 



20; the! driver 200 



sends 6 an inquiry request to 



20 for this : information and uses the 



^informat ion j returned to satisf y thej request of the user 
moc 



I . 
5de task 216. The types of requests that can be made by 

luser mode tasks 216 are very diverse, and the action 

itakes varies widely. In some cases! the request can be 

25 (Satisfied immediately,, and in some cases the user mode 

^task 216 must be fput to sleep until [ the request can be 

completed. | , js« 

When a user mode task 216k makes the last close 
? i ' : f r 

«to the TTY port 2!p4 , the host joperating system calls the 

30" close routine of it he driver 200. This causes the driver 

I ' 1 ' ! 
200- to put the user mode task |216 to sleep, to wait until 

* ..all the data in the transmit buffer 208 has been 1 

I . - t[ ■ . < - 

.transmitted and toj wait until !any pjending request] to the 
server 20 are complete. The driver! 200 then sends a 

35-- idose request • to j^the server, 20 . Upon receipt of i the 

I ' " » I ' J 

close request, the, server 20 de- allocates the -port 40 and 

l : 
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10 



-possibly reallocates it to another client 18. The driver 
200 then completes the close, and the 'user mode task 216- 
continues. • ^ f > ! 

! To optimize the efficiency of the operations of 



5 the driver 2 00> audi minimize the 4 load on the host 

operating system 215, 'driver 2C>Q l ! communications -to the 
. server 20 are made at periodic intervals about -fifty 
times/second. ^ At each such interval, Itjhe driver 200 



inspects each active port 204 tn'at is open to that server 
20, and places 1 ' requests and data for all such ports 204.- 

! i 1 ! ' 

40 into a common message, and sends that message to the 

I ^ *, • . 1 I 

server 20 as a ; single operation 1 . * This [action minimizes 

TCP/IP messages (or] other general 



the total number of 



the current 
be used to 



purpose network messages) that must be sent to. the server 
t i; i ■ - . I - 

15 20, and so enhances (the operation of the system. 

' It should j be recognized that 

invention provides a protocol whiich can 

i j ! ] 

simulate serial port hardware across a network 10. When 
used in this manner, a board or' b'ther (hardware is 
20 installed in a 1 host computer in such a way that it 

provides a serial port interf ace-l'to thej host computer 
similar to a local serial port board. In this 
embodiment, the board contains a* general -purpose network 

; I) i 

protocol stack; in addition to other software that 
25 provides the serial port interface and the functionality 
described above in connection with the' client driver 200. 
Using this board, drivers can be' 1 used ! oii the host 
operating system that are aware of only a serial port 
interface, and i are unaware of the' existence of the 
30 network 10. ' 1 - 

Such » a hardware implementation .has several 
advantages. First, it can be used to emulate a hardware 
or software interface for which' drivers) are already 
available (or- can easily be adapted) on the host 
35 operating system. Second, the board can be installed in 
a computer where networking hardware or software is not " 
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10. 



15 



20 



25 



30- 



35.- 



readily available, thereby providing network services to 

the host computer!. Third, the board can include an 

additional processor and hardware which off-loads much of 

the serial port overhead onto the card. Finally, such a 

i * ,f t I 

card could be multi-functional in nature by containing, 

I ^ ! I | j 

for example!, a small number ,of physical devices that 

1 I ' ' i 

could either be reserved for the local computer or be 

I .*_-.!'*! ' f I 

network accessible. . 

f r ■ j i 

All information, including data and commands, 

exchanged between the server 20 and .the client 18 is sent 

I i I ; 1 f | 1 • 

over the byte stream provided by the network protocol in 
small units called ^packets . The format of these packets 
makes up the ! Communication Protocol , of the present 
-invention, 
similar in 
that the fi 
format and 



The Communication Protocol packets are 

r ' i i 

format), 1 to CRT terminal escape sequences, in 

i ■ f ■ I i i * 

rst few bytes of the sequence determine the 

length!, ( of the data that follows. i 



The creation of the packets for communication 

I t . H'i! : < j ; . 

from the server 2jD,|to the client 18 j takes place in the 
CPU 32 of tbe server 20. Packets that are sent from the 

j j | ( I 

client 18 to the server 2 0 are. created by the special 

| '! i " 1 

driver operating on the clientj 18. jThe packets I 

themselves ! have a variable format and variable length, 
i ft* | j , 

depending on the .type of information they contain. The 
I ' f -'-.j [ i , t 

format of each packet is determined | by processing it 



sequentially. 



determines 
follow. 



The 



value of earlier 



bytes completely 



the format and content of the bytes that 

! M 

Table 9, shows the different types of packets 

I I M i 1 

which can be sent between a server 20 and a client 18. 

I 1 ' r • 

The -table shows how the first byte breaks down a packet 

subtypes . 



_into major 



Values denoted illegal were hot 



supported in the preferred embpdiment of the present 
invention, j- t 

Data packets are" used to send all in-band data 
between- the client 18 and server 20. When received by 



WO 95/25311 



PCT/US95/03183 



- 34 - 

the server 20, the data in the data packets are 
transmitted through to the appropriate port 40 as 
described above. 

window sequence packets inform the receiver 
5 about the state of the sender's sequence numbers. The 

transfer of this information is essential f or_ the working, 
of the data flow control of the present invention, as 
outlined above. Window sequence packets are used by the 
server 20 to send TOUT to the client 18, and are used by 

10 the client 18 to send RWIN to the server 20. 

Command packets have different formats and 
different lengths depending on the value of the command 
type field in byte one.' Commands are sent to set and to 
query about the values of the server state variables 38. 

15 In addition, command packets are utilized to open a port 
40, allowing the client 18 to guarantee synchronization 
with the server 20, to ascertain the size of the server 
transmit and receive buffers 42, 44, to ascertain the 
capabilities of a particular port 40, to flush the 

20 buffers 42, 44 of the server 20, to send a break or an 
immediate character and to pause or restart input or 
output. The command packets implemented in the preferred 
embodiment are set forth in Table 10. 

Two of the most important command packets 

25 involve communication between the client 18 and the 

server 20 in connection with opening a port 40. The Open 
Request command for opening a port 40 is sent by a client 
18 who wishes to obtain exclusive access to a port 40 on 
a server 20. When the server 20 receives an Open Request 

3 0 command, the server 20 attempts to open the port 40 for 
the client 18 and then responds with an Open Response 
packet which informs the client 18 of the results of the 
open attempt. 

The format of the Open Request Command Packet 

35 and the Open Response Command Packet are set forth .in 
Tables 11 and 12 . " - 
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20 



25 



30 



35 



40 is^valid and immediately available. If 
is not immediately available, the request 



The command packet to open a port 40 can take 

different -forms, depending on which f type of open command 

is desired by the;, requesting . client f 18 . The possible 

types of open commands are an immediate open, a 

5 persistent open, an incoming open. \ 

I t f 
A request for an immediat^ open succeeds and 

the port 40^ is assigned to the j requesting client 18 only 

if the port • ■* • r 

the port 40 

10 fails. 

When a persistent open request is made, the 
request willj succeed and the port 40 will be assigned to 
the client 18 if the port 40 is available. If the port 

I'M ; f t ; 

40 is busy, the server 20 returns aij Open Response packet 

15 to the client 18 which indicates the port 40 is busy, and 

then places the client 18 on ajwaitijng list for that port 

40. When ttie porp [40 subsequently fcjecomes available, the 

port 40 is opened*,, Jand the client 18 is notified with a 



second Open 



Response indicating success. 



Ttie third type of |open request is a request for 



open, -y, ,^This request succeeds immediately if 



an incoming 

the port 40 is available, and a carrier is present on the 
port 40. If . the port - 40 is busy, ox; if a carrier, is not 
present, the server! 2 0 returns the corresponding ^Open 



18 on a waiting list 
subsequently becomes 
port 40 is opened, 



1 f 

Response code and* /places the client 
for- that port 40.|.j$;When the port 40 
available with carrier present \ the 

and the clijent is) is not if ied~irith c. second Open Response 
indicating success. j 

aI client '18 may alsoj send a cancel waiting type 
"of Open Reques|t f j 3 ^ a particular poijt 40. When this 

- command 'is received from a client itj f the server 20 
checks to sjee if the client 18 j is on the waiting jlist for 
that port 40. If the client 18 is found on the list, the 

- client 18 is removed, and the server 20 returns an i Open 

I I ! i 1 - ' ' 

Response . indicating success 



• 
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It is possible to organize ports 40 on a server 

2 0 into a port hunt! group. - When 1 this "is done, the server 

20 provides one or. more logical ports designated as hunt 

1 i 'i I 

group ports so that| any attempt* to open one of these 

ports in fact fopensi a physical 'port 40 configured as a 

member of the fount group. Thus,! if a client 18 - requests 



20 



a port 40 which is part of a port hunt 



port 40 opened will 



be different from 1 the port 40 



requested. The client 18 must 1 inspect 



group, the actual 



the PNUM portion 



10 of the Open Response after a successful open, and use 

i I 1 i 

that port number for all subsequent references to the 



port 40. 

The Synchronization Request t command causes the 
recipient to respond with a Synchronization Response. It 



15 has no other ejffectL The primary purpose of this command 
is to allow the client to guarantee synchronization with 
the server. For example, a client 18 may wish to confirm 
a requested ba'ud rate change before returning to the 
calling program. The client 18 'achieves this by first 
sending a baud rate' change to 4 ne server 20, and then 



following it with a 
server 20 processes 



Synchronization Request. Since the 
commands sequentially, when the 
client 18 receives the matching it he Synchronization 
Response, the client 18 can be confident the baud rate 
25 change has been accomplished. i{ j I 

j The jsequeiice Request 'and Response Packets are 

provided so the client! 18 can accurately track the flow 
of data in and out of 'the server i 20. The server 20 
responds to this packet by providing RIN and TOUT to the 
30 client 18. I j ' I 1 

The client 18 may send -a Status Request Packet, 
to discern the current state of ESTAT and MSTAT in the 
server 20. The server 20 returns the requested data in a 
Status Response Packet, and takes no other action. . This 
35 command is one* of two ways the client 18 may learn jthe 
status of server 20. The client 18 may .also use the 



WO 95/25311 



PCT/US95/03183 



- 37 - 



15 



20 



30 



Select Event Conditions Packet to have the server 
t automatical ly report selected status changes as they 
occur. - ! 

i 

The client 18 sends the Line Error Request 

Packet to poll the line error counters, to configure 
i I | ; I 

periodic reporting, of line error counters, and to clear 

I : i i t 

the counters. The .server 20 sends a> Line Error Response 
in response to a poll for the error counters, and also at 
periodic intervals as configured with the variable LTIME. 



10 All Line Error Request packets 



may set the server 



variable LTIME. An LTIME value of 0, disables automatic 



jreporting. 
.unchanged. 



server 



An LTIME value of FFFF leaves LTIME 

s f ; I j 

After the* client 18 has set LTIME non-zero, the 

r f i i 

20 inspects the state of the error counters every 

I 1 I 1 I 1 f 

I LTIME milliseconds,, A to an accuracy of approximately 2 0 

1 : i nl ! . . 

milliseconds )i and !,sends an automatic Line Error Response 



packet if they have 



changed since the last report. 



The Buffer Request, Packet 'is sent by the client 
the size of the server transmit buffers 42 



18 to. learn 
and receive 

Buffer Response Packet 



buffers' 44. 



The server ;20 responds with the 
After 'a successful open, and 
before sending data to the server 20j, the client 18 needs 
, to ascertain the fize of the server'fs buffers 42, 44. 

25 The size of the transmit buffer 42 is needed so the 

■ " 11 - I 1 

client 18 can know, how much data the, client 18 is allowed 

i 1* ( \ y 

to- send. The size, of the receive buffer 44 is needed so 



the server 20 can (l set the flow 
marks accordingly.. 



control high and low water 



The Port capability request packet is generally 



sent- by the 



client 18 to learn I the capabilities of the 



hardware and' software of a port 40. i Unlike other port- 

I i 1 (!.*■} ■ - - j 

level, commands, thei port 40 need not! be open when this 

"I ! 
command is issued. 
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The Set Baud Rate command is used by the .client 
18 to set the port baud -rate, CFLAGS, I FLAGS, -OFLAGS and 
XFLAGS of a port 40. 

The client 18 sends the Select Event Conditions 
5 command to specify which ESTAT and MSTAT conditions cause 
the server 20 to send an Event Packet. The client may 
also poll for ESTAT and MSTAT using the Status - Request 
Packet. 

The Set Window Trigger command allows the 
10 client 18 to set TREQ, one of the server status variable- 
38. TREQ is the client 18 requested level at which a 
Window Sequence Packet should be sent. If TREQ is 
outside the range of data currently in the output buffer, 
the server 2 0 immediately responds with a Window Sequence 
15 Packet. 

The Set Modem Outputs and Flow Control packet 
is sent by the client 18 to set modem outputs, and select 
modem- signal hardware flow control. Note that when RTS 
and DTR modem flow control are selected, the values of 

20 RTS and DTR in MOUT are ignored. 

The client 18 sends the Set Receive High/Low 
Water Marks packet to set receive flow control high and 
low water marks. When this packet is processed by the 
server 20, if takes effect immediately. If the number of 

25 characters in the input buffer exceeds RHIGH, flow 

control is immediately invoked. If less than RLOW, flow 
control is immediately released. 

The client 18 sends the Set Flow Control 
Characters packet to set server 20 software flow control 

30 characters. Similarly, the client sends the Set RMAX and 
RTIME command to set the parameters RMAX and RTIME and 
the Set TMAX and TTIME command to set TMAX and TTIME. 

The client sends the Send Character Immediate 
packet to send -a character ahead of in-band data. In - 

35 sending immediate data, "software flow control is ignored, 
and hardware flow control uses the variable" MCTRL instead 
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15 



20 



25 



30 



of MFLOW. The client 18 utilizes the Send Break 
Immediate packet t-o send a hardware break signal. The 
Break signal is also sent ahead of all in -band data, and 
regardless of software or hardware flow control. .. 

The client sends Flush Buffers packet to, flush 
either or both the * server input and i output buffers. The 
Pause Input/ Output ; packet pauses any set of software flow 
control conditions in the server. It is ineffective to 
attempt to pause input if the number of characters in the 



10 receive buffer is, less than RLOW. 



finally, 



the Unpause 



unpause any set of 



ft; , 

Input /Output | packed is used to 

software flow control conditions in * the server. It is 

I I f ■"■ t ' j ' 

ineffective to attempt to unpause input if the number of 

characters -in the, ^receive buffer is (greater than RHIGH. 

Event packets are 'sent by .jthe server 20 to 

inform the clienti 18 of changes in ESTAT and MS TAT 

I i > ! : ¥ I 

conditions. The server 20 sends an 'event packet for each 

port 40 whenever : ETRAN & EINT) or ' t (MTRAN & MINT) ; are 



non- zero. 



To assure this requeist' does not cause 



to be 



transitions 
in event packets, 
MLiAST as follows , [ 
client 18 . 



ELAST 

[ ■ 
ETRAN 



MLAST 
MTRAN 



,lost that would otherwise be reported 
the server 20 first sets ELAST and 
and then reports ELAST and MLAST ; to the 



i J 



; (ESTAT * i ELAST) f (ETRAN & EINT) 



I ESTAT 



ELAST 



L = f (MSTAT " MLAST) 



MS TAT 



MLAST 



(MTRAN & MINT) 



used to select a 



* Module Select Packets are 
I !* ' S - - ! 

particular .grouping of ports 40. To reduce communication 

bandwidth, ports 40 are logically grouped into" modules, 

with each module .containing only sixteen ports 40 (ports 

0-15) . -There need be no relationship between a logical 
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module grouping and the physical^ layout of the ports 40 

on the server (s). By grouping sports 40 into modules, the 

addressing in all commands and responses references jaeed 

to only refer to which port (0-15) is desired within the. 

5 current module'. Module 0 is selected tiy default. 

Modules 0-7 can be selected witn^a one ibyte module select 

! ! j 
packet. Modules 8-255 require a two-byte packet. It is 

possible to convert i between a module arid port pair and a 

j I i '1 

physical port number. When module n is selected, port K 

10 in all subsequent packets refers' 1 to physical port 16*n+K-. 

An ID request packet 'is sent by either the 

client 18 or server i 20 to get identity or configuration 

ill i i 

information from the remote. The remote responds with a 

corresponding ID response packet'*. I 

15 The debugging packet types supports access to. 

pbrts 40 of the server 20 for debugging purposes, such" as 
transmitting debugging data between the' client 18 and 
server 20. These packets could also be used to allow the 
client 18 access to the server program memory 36, either 

20 to review the contents of program memory 3 6 or to change 

the programming of the server 20^as stored in program 

memory 3 6. j* J f * i 

The reset 'packet type is sent by a client 18 or 
! J 1 I 

server 20 to report ia protocol error to, the remote, prior 

25 to shutting down the connection t The packet contains an 

explanation of I the reason for the reset in an ASCII 

format . The Reset Packet should be the last packet sent 

in a conversation. V 

! Although tihis discussion has not specifically 

1 ^ » i i ' * 

30 covered operating systems, other than UNIX, it will be 

obvious to .one 1 skilled in the art that there are features 

i i j 

documented in XFLAGS, the error counters and the event 

flags that are required to satisfy the application 

programming interfaces of Novell", Windows, Windows NT, - 

35 OS/2 and DOS. As a 'result, the' implementation of the 

t - K 
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t } 
5 



invention in any of these operating systems is obvious to 
one skilled in the art. 

I '! 

The invention is not to be taken as limited to 



all of the 
variations 



details thereof as modifications and 



thereof may be made without departing from the 



spirit or scope of the invention. 



.11. j 



fV ■ 

fV. 



t i 

) 1 



HI. 
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Table 1: Server State Variables 



10 



15 



Type of Server State Variables 

Client Connections 

Message Build Interval 

Port Open State ~ 

Port Baud Rate 

Processing Flags 

Flow Control Characters 

Modem Control 

Line Error Counters 

Send Break and Send Immediate 

Event Reporting 

Input Sequence and Receive Buffer 
Parameters 

Output Sequence and Transmit Buffer 
Parameters 



Frequency 
per server 
per server 
per port 
per port 
per port . 
per port 
per port 
per port 
per port 
per port 
per port 

per port 
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Table 2: XFLAGS Settings 



Mask 
0001 
0002 
0004 

0040 
2000 



Name 

i 

XPAR 
XMODEM 

XCASE 

I 

XTOSS 
XIXON 



Description 
Enable Mark/ Space parity. 

Enable in-band ^modern signaling. 

H -if . 

Convert special characters to multiple - 

character sequences on output. 
Toss IXANY characters. 

Enable a second set of Output Software Fl 
Control Characters . 
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Name 
MOOT 
MFLOW 
MCTRL 
MSTAT 
MLAST 
MTRAN 

MINT 



i Table 3: Modem Variables 

Description 

i 

Client specified modem output values. 

i 

Modem flow control for in-band data. 
Modem flow control for out -of -band data, 
Current modem status. 

Last modem status sent to the client. 



Set of modem signals which 
those changes have not yet 
client. 

Modem signal change s { to be 
client. 



have changed, but 
been sent to the 

reported to the 



j - - '»l 
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Table 4 : Modem Signals in Modem Variables 



Mask 


Name 


Description 


01 


DTR 


Data Terminal Ready. 


02 


RTS 


Request To Send. 


10 


CTS 


Clear to Send. 


20 


DSR 


Data Set Ready. 


40 


RI 


Ring Indicator. 


80 


DCD 


Data Carrier Detect. 



'it 



IS 



V. 
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Table 5: Event Reporting Variables 

Name Description " ~ - ~ - 

ESTAT Current state of event conditions. 

ELAST Last state of the event conditions sent to the 

client. _ - " 

s> - - 

ETRAN Set of event conditions which have seen 

transitions, but those transitions have not 
yet been reported to the client. 

EINT Set of event conditions which cause an event 
to be generated. 
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Table 6 : Recorded Events 

Mask Name Description 

0001 OPU Output paused unconditionally by client. 

0002 OPS Output paused by regular software flow 

I'l ! I 

control . 

0004 OPX Output paused by extra software flow control 

1 

1 characters . 

! il , • 

0008 OPH Output paused by hardware flow control. 

i W \ 

0010 IPU Input paused unconditionally by client. 

| \ 

0020 IPS Input paused by high/low water marks. 

0040 TXB Transmit break pending. 

0080 TXI Transmit immediate pending. 

i 

0100 TXF Transmit flow control character pending. 

0200 RXB Break received. 
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Table 7 : Input Sequence and Receive 1 Buffer Variables 

Name Description " . I " -. 

RIN Sequence number of the next byte of data - to be 

read from the UART and placed in the local 

I _ 
receive buffer. 

ROUT Sequence number of the next j byte to-be 

transmitted from the ( receive buffer to the 
client, j | 

RWIN Highest Sequence number the client wishes to 
accept. ( 

RMAX Receive trigger maximum. 

RTIME Receive trigger time. 

RSIZE Size of the local receive buffer. 

RLOW Software flow control low water mark. 

RHIGH Software flow control high water mark. 
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Table 8 : Output Sequence and Transmit Buffer Parameters 

Name Description 

TSIZE Size of the transmit buffer in bytes. 

TIN Sequence of the next byte to be placed in the 
transmit buffer. 

TOUT Sequence of the next byte to be sent from the 
transmit buffer out the port. 

TPOS Value of TOUT last reported to the client. 

TMAX TOUT report maximum. 

TTIME TOUT report time (milliseconds) . 

TREQ Client requested sequence number. 



,> 1 1 



SUBSTITUTE SHEET. (RULE 2e) 



! 



WO 95/25311 PCT/US95/03183 



- 50 - 

Table 9 : Packet Types 

Nibble 0 Nibble 1 Description • ~ * - 

0 port 0-15 Data Packet. 1 byte of data follows 

for the specified port. 

1 port 0-15 Data Packet. 2 bytes -of - data follow 

for the specified port.- 

5 2 port 0-15 Data Packet. 3 bytes of data follow 

for the specified port. 

3 port 0-15 Data Packet. 4 bytes of data follow 

for the specified port. 

4 port 0-15 Data Packet. 5 bytes of data follow 

for the specified port. 

5 port 0-15 Data Packet. 6 bytes of data follow 

for the specified port. 

6 port 0-15 Data Packet. 7 bytes of data follow 

for the specified port. 

10 7 port 0-15 Data Packet. 8 bytes of data follow 

for the specified port. 

8 port 0-15 Data Packet. Byte 1 of the packet 

specifies 1-255 bytes of data 
following for the specified port. 

9 port 0-15 Data Packet . Bytes 1-2 of the 

packet specify 1-65535 bytes of data 
following for the specified port. 

10 port 0-15 Window Sequence Packet. Bytes 1-2 

specify a window sequence number. 

11 port 0-15 Command Packet . Byte 1 specifies a 

command number which determines the 
length and format of the data that" 
follows. 
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10 



Nibble 0 
12 

13 
14 
15 



Nibble : 1 Pes cr ipt ion 



15 

15 
15 

15 

15 
15 

-15 



Event Packet . 
follow. 

! ■ 1 

Illegalt. t 

i i 

Illegal'. 



3 bytes of status 



port 0'-15 

t 

*iM < 
* < ; ■ t 

module' '6-7 Module select Packet . Nibble 1 

M i 



8 i»j 

n 

9-foj 

11 ; 

I 

12 

13 
14 

15 



contains the (module number to be 

i 

selected. . ( 

1 ' 
Module select Packet . Byte 1 

specifies a module select code in 

I i 
the range 0-255 . 

Illegal!. j 



ID Request packet . 
response . 



Requests an ID 



ID Response packet . Byte 1 
determines the size of the data 
whi ch f ol 1 ows . 

Debugging and Control Packet . 

Debug Packet . Specifies a number of 
following bytes to be utterly 
ignored. Used for stress testing. 

Reset Packet . Followed by a null- 
terminated ASCII string describing 
the reason for -the reset. 
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10 



15 



20 



Table 10 

Command Type 



Coxmnand Type Assignments & Lengths 

-I . i ■ " 1 
Command Length ! Command Name 



(byte 1 value) 
10 

ll i 

12 

13 

14 

15 

16 

17 

18 

19 

20 

21 j 
22 

23 : 
40 

42 
43 
44 

45 
46 



(bytes) 
3 
6 
3 
3 
2 
6 
2 
5 
6 

14 
2 

6 I 
2 

32 
12 

5 

i 

4 
5 

6 
7 



'Open Request 



J. 



'a! 



Open Response 

Synchronize Request 

J - » 
Synchronize Response 

Sequence Request 



it- 



is Sequence Response 



M- -Status 



Status 



Request 
Response 



/Line Error Request 1 

4 | 

Line Error Response 

'-i I 

; .Buffer Request 



i. Buffer 



Response 



; '/'Port Capability Request 

j '*Port Capability Response 

1 * \ . 

Set Baud Rate, C FLAGS , 

i I FLAGS*, OFLAGS and XFLAGS 

i :k ■ 

Select Event Conditions 

ir* 

i^Set Window Trigger 

tVSet Modem outputs and Flow 
.Control 

t Set High/Low Water marks 

Set Flow .Control 
Characters 
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Command Type 
(byte 1 value) 

47 , 

4B j 

60 ■•! 

61 
62 
63 
64 



- 53 - 

Command Length Command Name 
(bytes) 



6 
6 
3 
4 
3 
3 
3 



Set RMAX and RTIME 
Set TMAX and TTIME 
Send Character Immediate 
Send Break Immediate 
Flush input /output 
Pause input /output 
Unpause input /output 



i i 



PI 
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Table 11: Open Request Packet 



5 



Position 


Name 


Description 




Nibble 0 


MTYPE 


Message type 11: 


Command. 


Nibble 1 


PORT__ 


Port number 0-15 


* 


Byte 1 


CTYPE 


Command type 10: 


Open - Request . 


Byte 2 


REQ 


Request Type: 





0= Immediate open 
l=Persistent open. 
2= Incoming open. 
3=Cancel/Close immediate open 
4=Cancel/Close persistent or 
incoming open. 
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Table 12 : Open Response Packet 



Position | 


, Name 


Descriotion 




Nibble 0 


MTYPE 


Message type 11: 


Command . 


Nibble 1 


PORT 


Port number 0-15 


' !' 


Byte 1 


CTYPE 


Command type 11: 

t 


Open Response. 


Byte 2 


REQ 


Request Type:! 





0=Immediate open , 
l=Persistent open. 1 
2^Incoming open. 
3«Cancel/Close immediate open. 
4=Cancel|/Close persistent or 
incoming open. 

Byte 3 RESP Request code: 

0=Success . 
l=Port busy. 
2=No carrier. 

3-Resource allocation problem, 
try again. 

4=Request not supported on this 
device . 

Bytes 4-5 PNUM Actual port number (16*module+port ) 

opened by tnis request. 
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1 "~ ' Claims ^ - - " . 

A system for! communicating digital data comprising: 

a) a general purpose computer j network; 

b) a host computer operably connected to the 
general* purpose network having an operating 
system with an application programming 
interface for a local communication device; 

c) a device" driver means running on the host 
computer for implementing the application 
programming interface of tne local 
communication device'* and transmitting 
operations requested* by the application 
programming interface over the general purpose 
network; and l i 

d) an apparatus operably connected to the general 
purpose network having 

i) at least one communication device, and 

ii) an implementation means for implementing 
the operations requested by the 
application programming interface and 

t ransmi 1 1 ed over the general purpose 
computer network by the device driver 
means . 

The system of claim 1, further comprising device 
entities visible through the application programming 
interface, and wherein there is a one-to-one 
relationship between the device entities and the 
communication devices on the apparatus. 

The system of claim i, wherein the device driver 
means implements the application programming 
interface of the local communication device by 
utilizing a TTY device on the host computer for - ~- 
receiving and transmitting data to the operating 
system operating on the host computer. 
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The system; of claim 3, wherein the operating system 
is UNIX. ... 



5 ,6 



10 



15 



7. 



20 



8. 



25 



The system of claim 3, wherein the operating system 

is Novell Netware. , 

' i ^ 

I ; m • . \ ( f 

The system of claim i, wherein the device driver 

! H . t [ 

means further comprises, 

; "* ' | I 

a) , local implementing) means for implementing the 
i operations of the application programming 
interface which can be done locally are done 
jlocally at the hos£ computer, and 



b) 



The 



remote < implementing means for transmitting the 
joperations of the application programming 
jinterface which alter hardware characteristics 
of the ; communication device over the general 
purpose network ' to the apparatus for 
implementation by the apparatus . 

-Pi : ■ ( 



system of claim 6 wherein the remote 

! ill 

implementing means further comprises transmitting a 
portion of the operations of < the application 
programming | interface which could be done locally 
over the general purpose network to the apparatus 
for implementation by the apparatus in order to 
reduce the processing load on the host computer; 



The 



T 



system M of claim 1, wherein the apparatus is 



located phvsically distant from the host computer. 

j ' i M ' i ' 

9, The j system, j of claim 1, wherein the device driver 
'means is a .serial communication driver. 



10. . The system of claim 9 wherein the device driver is 
an asynchronous serial communication driver. 



l! 
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-sa- 
il. The system of "claim 1, wherein the apparatus, further 
- comprises a plurality of communication -devices . - 

12 . The system of claim 1 wherein the apparatus further 
comprises at JLeast one serial port. 

5 13 . The system of claim 1 wherein the device driver 
means on the host computer communicates with the 
apparatus over the general purpose network "through a 
reliable bi-directional bytestream connection. 

14. The system of claim 13, wherein the reliable bi- 
10 directional bytestream connection is a TCP 

connection. 

15. The system of claim 14, 17, wherein the bi- 
directional bytestream connection is a single 
bytestream connection which supports communication 

15 between the device driver means and multiple 

communication devices on the apparatus. 

16. The -system of claim l, wherein the device driver 
means further comprises open requesting means for 
requesting the communication device to grant to the 

20 host computer exclusive access to the communication 

device on the apparatus. 



17. The system of claim 16, wherein the open requesting 
means further comprises requesting the apparatus to 
place the host computer on a waiting list for the 
25 communication device where the communication device 

is not immediately available for the exclusive use 
of the host computer. 



18 . 



The system of claim 14, 17, wherein the open, 
requesting means further comprises requesting the 
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10 19. 



15 



20 



25 



20 . 



30 22 



apparatus to grant the host computer exclusive use 
to the communication device if the communication 
device is available and a carrier is present on the 
communication device and where the communication 
device places the host computer on a waiting list 
from which the host computer is removed and given 
exclusive access to the communication device when 
the communication device is available and a carrier 
is present on the communication device. 

! ' ! iH i i« 

The systemilof claim 16, [further comprising at least 
one additional host computer and wherein the 
apparatus grants exclusive access to the 
communication device toja particular open requesting 
means ! of a (particular host computer when the 

tippen requesting means requests access to 



I 



particular 
the communication device and 
device is available. 



the communication 



The system* of claim 1 wherein the device driver 

; ' ' ' | 

means, comprises a device driver installed into the 



UNIX, kernel .* 

I | ' 

i . u; 



21. The system 



Vpf claim 20, 



further comprising a UNIX 



opening a control |device associated with 



daemon means for establishing a reliable bytes tream 

I ,j j jj 

connection over the general purpose network;, with the 
apparatus , 

the 'devicej driver means!, and jutilizing the STREAMS 

interface to link the reliable bytestream connection 

I ' ■ fT: i ( ■ ! 1 

to the device driver ( means such that an application 

program isj not needed to send and receive data over 



the 



connection. i 



An improved E terminal j server of the type for 
providing access to a h'ost computer through a 
general purpose network^, and [having a network 
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interface device connected to the. general purpose 

network for (receiving and transmitting data across 

the general purpose network andj also having a 

plurality of communication devices available for 
i * i I 

5 communication with the host computer, the 

improvement .comprising : 1 _. 

i i . . i ' ; , ! i. 

a) a communication protocol rich enough to support 

all the common hardware" and software operations 

i | j j 

supported by the application programming 

t i ■ : t I 

10 interface of widely 'available operating 

systems; , ; j 

b) a translation means'^f or translating 'data 

received from the general' purpose network 

I ' [ 

according to the communication protocol ; 

15 c) an implementing means for implementing the - 

operations translated by the translation means. 

23. The system of claim 22, further 1 comprising : 

d) a data ^transmission control means for combining 
al!l data to be transmitted from the 
20 communication devices to the host computer into 

a 'singl'e byte stream protocol transmission 
across [the general purpose network. 

24. The system of claim, 22, further comprising: 
d) fiow control means for controlling the 

25 individual communication devices is independent 

'I 1 v ' ■ 

of the flow control ^f or the reliable by test ream 

connection. »3 I f 

I i - h 

25 . A method for transmitting: data and commands from an 
operating system running 'on a host computer to a 

30 serial 'device attached to a terminal server across a 

general" purpose network, "the method comprising :- 
a) receiving data and commands directed toward the 
network 1 device from the operating system so 



« 
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10 



15 t 



20 A 



26. 



25 i, - 



30" - , 



b) 
c) 
d) 



e) 
f ) 



g) 

h) 
i) 



that the operating , system acts as if it is 
communicating with! at least one locally 
connected device; 

storing the data and commands received from the 
operating system in a host receive buffer; 
formatting jdata jand commands into a plurality 
of packets .according to a protocol; 
transmitting the packets^ from the host computer 
to the terminal server across the general 

i 

purpose network utilizing a reliable, bi- 
i directional byte stream connection; 
receiving the packets at the terminal server; 
translating the packets ' received at the 
terminal server ; into the data and commands sent 
by. the,/ operating system^ 

storing the data in a terminal server transmit 
buffep | 

performing ! the operations requested by the 

commands sent by the operating system; 

i i , - i 1 j : if 

transmitting the data stored in the terminal 

server transmit buffer to the serial device. 



A system for communicating data comprising: 

a) : ' - 1 



b) 
c) 

d) 



a general purpose network; 
a hospi jcomputer operating on the network; 
a communications server j operating on the 
network; , j 

a device driver means operating on the host 
compujter for providing a set of device entities 
which ( appear to applications running on the 
host computer .to be local devices and which are 
actually located on ,the communications server. 
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